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TITLE OF THE INVENTION 

Process for Managing Change within an Enterprise 

FIELD OF THE INVENTION 

The invention is a method for managing change within an enterprise, more particularly for 
auditing and communicating changes made to electronic computing systems of the enterprise. 

BACKGROUND OF THE INVENTION 
[0001] Changes occur frequently in the processes and equipment of businesses and other 
enterprises and adverse effects can occur when unauthorized changes take place. Electronic 
computing systems, in particular, often undergo various modifications and unintended results can 
readily occur if the modifications are not approved by a knowledgeable authority or are not 
adequately communicated to all parties that might be impacted. Thus, a process for managing 
change comprising a centralized control agency is desirable to review, approve, document, and 
communicate changes taking place within an enterprise. 

SUMMARY OF THE INVENTION 
[0002] The method of the present invention, referred to herein as the Change Management 
Procedure, enables businesses and other enterprises to effectively manage, record, and 
communicate changes that occur within the enterprise. While the Change Management Procedure 
is applicable to any type of change, in a preferred embodiment the procedure manages 
modifications in electronic computer systems including, but not limited to, architecture changes, 
outages (e.g., hardware, software, or facility), replacement of hardware, upgrading of software, and 
rebooting of devices. By requiring that all changes be formally requested and approved, the 
Change Management Procedure prevents unauthorized changes. The Change Management 



Procedure also creates an audit trail that keeps a record of all changes for future reference. 
Another advantage of the Change Management Procedure is the communication of changes to 
operating units within the enterprise that are potentially interested in the change. At any step 
within the Change Management Procedure, entities that might be affected by a change may be 
notified of the change. Thus, potentially interested operating units can be aware of changes before 
they occur and can be informed of all changes that have occurred. 

DESCRIPTION OF THE DRAWINGS 
[0003] The invention, together with further advantages thereof, may best be understood by 
reference to the following description taken in conjunction with the accompanying drawings in 
which: 

[0004] Figure 1 A is a flowchart depicting the steps in a planned change request process. 
[0005] Figure IB is a flowchart depicting further steps in the planned change request process. 
[0006] Figure 2A is a flowchart depicting the steps in an emergency change request process. 
[0007] Figure 2B is a flowchart depicting further steps in the emergency change request 
process. 

[0008] Figure 3 is a printout of a computer screen depicting a web page used for logging in to 
the change management system. 

[0009] Figure 4 is a printout of a computer screen depicting a web page used for viewing 
active change requests. 

[0010] Figure 5 is a printout of a computer screen depicting a menu of options available for 
users with security level 3. 
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[0011] Figure 6 is a printout of a computer screen depicting a menu of options available for 
users with security level 4. 

[0012] Figure 7 is a printout of a computer screen depicting a web page used for user 
registration. 

[0013] Figure 8 is a printout of a computer screen depicting a web page used for submitting 
change requests. 

[0014] Figure 9 is a printout of a computer screen depicting a web page used for managing 
email distribution groups. 

[0015] Figure 10 is a printout of a computer screen depicting a web page used for editing 
email distribution groups. 

DETAILED DESCRIPTION 
[0016] Management of change in the Change Management Procedure is achieved through the 
use of a change request document. The change request document can be a paper form, an email, a 
web page, or any similar means of documenting the changes to be made and the steps taken in the 
implementation of the changes. The entity requesting the changes and responsible for ensuring 
that the change request document is complete and accurate is known as the change requester. 
Alternatively, one entity can complete the change request document and another entity can ensure 
its completeness and accuracy. In this case, the entity completing the change request document 
would be known as the change requester and the entity ensuring its completeness and accuracy 
would be known as the change owner. For purposes of this application, unless otherwise specified, 
the change requester and the change owner are considered the same entity and are referred to as the 
change requester. The entity that manages changes and oversees the Change Management 
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Procedure is known as the change manager. The change requester can be considered a client of the 
change manager. If the change requester and the change manager are members of different 
enterprises, a client service manager may be employed to act as a liaison between the change 
requester and change manager. In the case where the need for a change is identified by the change 
manager, the change manager can also function as the change requester. Implementation of 
changes is typically accomplished by an entity designated by the change manager or the change 
requester. The change requester change manager, change implemented and client service 
manager can be either individuals or organizations. 

[0017] Access to the Change Management Procedure may be restricted to registered users 
authorized to submit change requests via the change request document. Registration can be done 
by means of a paper form, an e-mail, a web page, or any similar means of documenting 
information about the entity requesting authority to submit change requests. The registration 
documentation is submitted to the change manager for approval, which may further comprise 
checking to ensure that data has been entered in all fields of the registration form and/or 
performing background checks on the user submitting the registration form to ensure that the user 
has the proper authority and/or knowledge level to submit change requests. 
[0018] Within the Change Management Procedure, different levels of authority may exist for 
users who submit change requests based upon a security clearance level and corresponding to an 
approved set of operations (such as viewing, editing, and/or submitting a change request 
document) that the change requester may perform. For example, the lowest level (0) could be new 
users who have submitted registration requests but whose registration requests have not yet been 
approved. Such users would be allowed access only to the registration form. The next highest 
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level (1) could be users who are not employees of the same company as the change manager and 
are not under contract to that company but who may have a need to submit change requests. Such 
users would be allowed limited ability to complete and submit the change request document but 
would not have access to change requests made by others. The next highest level (2) could be 
users who are not employees of the same company as the change manager but who are under 
contract to that company. Such users would be allowed to complete and submit change request 
documents and would have access to change request documents submitted by others within their 
organization. The next highest level (3) could be users who are employees of the same company 
as the change manager. Such users would be allowed to complete and submit change request 
documents and would have the authority to see the change requests submitted by all other users. 
The highest level (4) could be members of the change management organization. Such users 
would have the authority to edit the change requests submitted by all other users. 
[0019] A change can be either planned in advance or necessitated by an emergency. Planned 
change management is typically achieved through the following steps: submission of a change 
request document from the change requester to the change manager, broadcasting notice of a 
proposed change to potentially interested operating units within an enterprise, review of the 
proposed change by a change review team comprising the change manager and representatives of 
other potentially interested operating units who choose to participate, approval or rejection of the 
proposed change by the change review team, scheduling of an approved change by the change 
manager, possibly with input from the change review team, and implementation of the approved 
change by an individual or organization the change requester or the change manager designates. 
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These steps, and variations and combinations thereof, constitute embodiments of the Change 
Management Procedure and are described in detail below. 

[0020] The first step in the Change Management Procedure is typically the submittal of a 
change request document from a change requester to the change manager. The change request 
document typically includes information such as a description of the proposed change, justification 
of the proposed change, the predicted results and impact of the proposed change, the preferred date 
and time for implementation of the proposed change, and a plan for reversing the proposed change 
if implementation is unsuccessful. The change requester is responsible for ensuring that the 
change request document is complete and accurate. 

[0021] The next step in the Change Management Procedure is typically the validation of the 
change request by the change manager. In the validation procedure, the change manager checks 
the change request document to ensure that it has been completed fully and accurately but no 
evaluation is made of the merits of the proposed change. If errors are found in the change request 
document, the document is returned to the change requester for revision. If no errors are found, the 
review process is initiated for the change request. 

[0022] After validating a change request, the change manager sends notification about the 
proposed change to at least one representative of each operating unit within the enterprise that is 
potentially interested in the proposed change. Notification can be achieved through email, 
telephone, or other means of communication and is typically broadcast widely within the 
enterprise. For example, the change manager may maintain email distribution lists of operating 
units that are potentially interested in changes. The members of the lists may vary based upon their 
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interest in disparate types of changes, and the change manager would choose the appropriate list to 
be notified for a proposed change. 

[0023] All proposed changes are reviewed by a review team comprising the change manager 
and a representative of each potentially interested operating unit receiving notification of the 
proposed change and choosing to participate in the review team. The review team will recommend 
a course of action with respect to the proposed change, typically either approving or rejecting the 
proposed change, and will notify the change requester of the recommendation. If the proposed 
change is rejected, the change requester can either cancel the request or revise and resubmit the 
request. If the proposed request is approved, the change requester establishes a schedule for 
implementation of the change. Other members of the review team may offer input into the 
scheduling of the change. The potentially interested operating units can then be notified of the 
schedule for and the details of implementation of the change. 

[0024] When a change is implemented by the change requester or a designee of the change 
requester or change manager, the implementation can occur as requested or some modification to 
the change as proposed may be necessary. If the change is implemented as requested, the change 
request document can be updated with information regarding the work that was done and all 
potentially interested operating units can be notified that the request was completed. If an asset 
management agency exists to oversee an organization's physical assets and the physical assets of 
that organization are impacted by a change implemented through the Change Management 
Procedure, the asset management agency can be notified of the change and their asset inventory 
and/or maintenance records updated accordingly. 
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[0025] If a change is not implemented successfully, the request for the change can be cancelled 
or the change can be rescheduled. If the request is cancelled, the steps taken in the attempted 
implementation of the change can be reversed, all potentially interested operating units can be 
notified, and the change request document can be updated with a description of the work that was 
and was not done and the reason for the cancellation. If the change is rescheduled, the partial, 
successful steps taken in the implementation of the change can be left in place, any remaining steps 
to be taken in the implementation of the change can be rescheduled, all potentially interested 
operating units can be notified, and the change request document can be updated with a description 
of the work that was and was not done. 

[0026] When change requests are completed, whether the change was successfully 
implemented or not, a review of the change implementation process can be performed and reports 
can be created describing the results of the review. 

[0027] In the preferred embodiment, the Change Management Procedure may be used to 
manage modifications in electronic computer systems including, but not limited to, architecture 
changes, outages (e.g., hardware, software or facility), replacement of hardware, upgrading of 
software, and rebooting of devices. Due to the highly interconnected nature of many computer 
systems, changes such as these in one part of a system can cause unintended effects in another part 
of the system. Use of the Change Management Procedure ensures that organizations and/or 
individuals within an enterprise that are potentially affected by a proposed change to a computer 
system are informed of the proposed change and are given the opportunity to offer comments on 
the scheduling, implementation, and consequences of the proposed change. Revisions to the 



proposed change can then be made, if necessary, so that all interested parties grant approval to the 
proposed change. Unanticipated adverse effects to computer systems can thus be minimized. 
[0028] The Change Management Procedure can be applied to operating units within a single 
enterprise or to operating units in multiple enterprises. For example, the change requester and the 
change manager can be members of different departments within the same company. 
Alternatively, the change requester could be a member of one company and the change manager 
could be a member of another company. In the latter case, the change manager's organization may 
employ an individual or a group to act as a liaison between the change manager and the change 
requester. 

[0029] When changes must be made due to an emergency, the procedures for planned change 
management cannot always be followed. In an embodiment of the Change Management 
Procedure, an emergency change request process can be instituted to manage changes that must be 
made on an emergency basis or in response to problem tickets generated through a problem 
management process. 

[0030] Many organizations have a process for handling problems in which a document 
describing the problem is created and then assigned to the proper group for resolution. Any such 
document used in such a problem management process will be referred to as a problem ticket. 
Problem tickets are often assigned severity levels depending on the seriousness of the problem. An 
emergency would have a high severity level while a minor problem that has few adverse 
consequences would have a low severity level. 

[0031] The emergency change request process is initiated in two ways: by the creation of a 
problem ticket requiring a change and by the occurrence of an emergency that does not require the 
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creation of a problem ticket. For high severity problem tickets that can be resolved immediately, a 
change request is not necessary before commencement of problem resolution activities — the 
severity of the problem serves as the approval to make any necessary changes. In this case, the 
change implementer creates an emergency change request document after implementation of the 
change is complete. This post-problem emergency change request, containing a description of the 
change that was implemented, is submitted to the change manager for record keeping purposes. 
[0032] For lower severity problems, high severity problems that cannot be resolved 
immediately, and emergencies not requiring a problem ticket, a modified form of the planned 
change request process is implemented. For emergencies not requiring a problem ticket, the 
change requester creates an emergency change request document and submits it to the change 
manager. In the cases where a problem ticket exists, the change manager reviews the problem 
ticket, determines that implementation of the change can be deferred, and notifies the change 
requester that an emergency change request must be submitted for approval. The change requester 
then creates an emergency change request document and submits it to the change manager. The 
change manager obtains approval for the change, a schedule for the implementation of the change 
is established with collaboration between the change manager, the change owner, and any 
potentially interested operating units, the potentially interested operating units are notified of the 
schedule, the change request is updated with the approval and scheduling information, and the 
change is implemented. The change request document is then updated with information regarding 
the change that was made, all potentially interested operating units are notified that the change has 
been completed, and the asset management agency is notified, if necessary. When the emergency 
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change process is complete, a review of the process can be performed and reports can be created 
describing the results of the review. 

[0033] If a change made in response to an emergency is not implemented successfully, the 
steps taken in the attempted implementation of the change are reversed, all potentially interested 
operating units are notified, and the change request document is updated with a description of the 
work that was and was not done. 

[0034] As is the case in planned change management, the emergency change management 
procedure can be used to manage modifications in electronic computer systems. The emergency 
change management procedure can also be applied to operating units within a single enterprise or 
to operating units in multiple enterprises. 

[0035] Use of the Change Management Procedure can be facilitated by implementing the 
procedure on an electronic computer system. In particular, the change request document can be 
placed on an interactive web page. Access to and authorization to enter data on this web page can 
be restricted to registered users according to their security clearance levels as described previously. 
Original submittal of and subsequent updates to a change request document would then be 
accomplished by an authorized change requester entering data into the fields of the online 
document and submitting the data to the change manager. The various notification steps within the 
Change Management Procedure, including broadcasting notice of a proposed change to potentially 
interested operating units, notifying the change requester of the review team's recommended 
course of action for a proposed change, and notifying potentially interested operating units of the 
status of a proposed, scheduled or implemented change, can also be accomplished electronically. 
These notification steps can be done through email or through updates to a web page accessible to 
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the potentially interested operating units. Likewise, the review team meetings can be held by 
means of broadcasted emails or publicly updateable web pages rather than face-to-face meetings. 
Any reports evaluating the Change Management Procedure can be distributed by similar means. 

EXAMPLES 
EXAMPLE 1: PLANNED CHANGE 
[0036] An example of the Change Management Procedure for a planned change is summarized 
in the flow charts in Figures 1 A and IB. The change requester is referred to as the change owner 
in the charts. In this example the change owner is not a member of the same enterprise as the 
change manager and therefore a client service manager is employed as a liaison between the 
change owner and the change manager. The change implementer can be a member of the change 
owner's organization, the change manager's organization, or a third party organization designated 
by the change owner or change manager. 

[0037] At steps 1, 2, 3, and 4 a need for a change is identified by a member of the change 
owner's organization, a member of the change manager's organization, a third party, or a member 
of the change manager's enterprise outside the change manager's organization, respectively. The 
change owner tests the needed change at step 6 to ensure that it can be implemented successfully 
and with minimal impact to others. The testing may include conducting peer reviews to ensure the 
change implementation will accomplish the intended result. The change owner completes a 
change request document at step 8 and submits the change request document at step 10. At step 20 
the change manager validates the change request. If a person within the change owner's 
organization has not been designated to take responsibility for the proposed change, the change 
manager designates such a person in step 24. The change manager, change owner, and client 
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service manager review the proposed change at step 28 and establish a tentative schedule for 
implementation of the change. At step 30 the change manager distributes the change request 
document to the review team. Preliminary approval or rejection of the proposed change by the 
review team occurs at decision point 40. If the proposed change is rejected, two options are 
possible at decision point 50. If all parties involved in the review process reject the change, then 
the change manager closes the change request document in step 60 and sends notification to all 
potentially interested operating units in step 70. If all parties involved in the review process do not 
reject the proposed change, then the change owner can revise the change request document in step 
80 and resubmit the document to the change manager in step 90. The Change Management 
Procedure then begins again at step 10 for the resubmitted change request. If, at decision point 40, 
the proposed change is approved, the change manager distributes the change request document to 
all potentially interested operating units in step 100. At step 110 a review meeting is held for a 
final clarification of any outstanding content, scheduling, or implementation issues. At step 120 
the change manager provides a finalized list of approved changes to the other members of the 
review team. 

[0038] The finalized change request document is distributed in a broadcast message from the 
change manager to all potentially interested operating units in step 122. At step 124 the change 
owner coordinates the approved change with the change implementer. At step 126 the change 
owner coordinates access to the facility at which the change will take place. At step 128 the 
change owner and/or the change implementer update the change request document with any 
information pertinent to the change management process as it has been implemented to that point. 
The change is implemented at step 130 and the change request document is again updated at step 
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140. When the implementation activities are complete, decision point 150 is reached. If the 
change was not successful, the change implementer reverses the attempted changes in step 160, 
updates the change request document in step 165, and notifies the change manager of the 
unsuccessful change implementation in step 170. The change owner updates the change request 
document in step 180. In an alternative course of action for an unsuccessful change, if the partial 
changes can be left in place in step 190 without impact, the remaining changes are rescheduled in 
step 200, the change implementer notifies the change manager as in step 170, and the change 
owner updates the change request document as in step 180. If the change was successful, the 
change implementer updates the change request document in step 210, notifies the change manager 
in step 220, notifies the change owner that the change has been successfully implemented in step 
230, and notifies the change owner of any problems that occurred or may occur as a result of the 
change implementation process in step 240. At step 250 the change manager closes the change 
request document and at step 260 the change manager performs an analysis of the Change 
Management Procedure as it was applied in the newly completed change. At step 270 the client 
service manager notifies the change owner's organization that the change has been implemented 
successfully. In step 280 the asset management agency is notified of any changes that were made 
to physical assets. 

EXAMPLE 2: EMERGENCY CHANGE 
[0039] An example of the Change Management Procedure for an emergency change is 
summarized in the flow charts in Figures 2 A and 2B. The change management process starts at 
decision point 310 where proposed emergency changes are divided into two groups: those related 
to severity level 1 or 2 problem tickets (the two most severe levels) and those related to lower 
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severity problem tickets or unrelated to the problem ticketing system. If the changes are related to 
severity 1 or severity 2 problem tickets, the change owner, in step 316, determines whether the 
resolution of the problem ticket can be deferred. If the resolution of the ticket cannot be deferred, 
the problem is resolved and then, in step 320, the change implementer creates a post-change 
emergency change request. If the resolution of the problem can be deferred, an emergency change 
request is created in step 330. The emergency change process then continues at step 340 as 
described below. 

[0040] For changes related to lower severity problem tickets and for changes unrelated to the 
problem ticketing system, the change owner, in step 314, determines that an emergency change 
request document must be completed. For these cases and for severity 1 or 2 problems that can be 
deferred, an emergency change request is created as in step 330. At step 340 the change owner 
notifies the management of the change owner's organization that an emergency change request has 
been created. At step 350 the change owner submits the emergency change request to the change 
manager. The change manager obtains approval of the request in step 360 and notifies the client 
service manager in step 362. The client service manager sends a broadcast notice of the approved 
change to the change owner's organization step 364 and obtains final approval in step 366. A 
schedule for implementation of the change is established by the change owner and the client 
service manager in step 370. In step 380 the change owner notifies the change manager of the 
schedule for the change. The change owner and/or the change implementer update the emergency 
change request in step 390. 

[0041] The change implementer implements the change in step 400. Alternative courses of 
action are taken at decision point 405 depending on whether or not the emergency change is 
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backed out. If the emergency change is not backed out, the change implementer notifies the 
change owner and the client service manager in step 410 that the change was not backed out. At 
step 420 the change implementer notifies the change owner of any potential problems created by 
the change. The change owner and/or the change implementer update the emergency change 
request in step 460 and the change implementer notifies the change manager in step 470. The 
change manager closes the emergency change request in step 480 and notifies the asset 
management agency in step 490. If, at decision point 405, the emergency change is backed out, the 
change owner and/or the change implementer update the emergency change request in step 430 
and notify the change manager and client service manager in step 440. If a third party other than 
the change owner and change manager is involved in the emergency change process, the client 
service manager notifies the third party in step 450. The change implementer updates the 
emergency change request in step 500 and notifies the change manager in step 510. The change 
manager performs an analysis of the Change Management Procedure as it was applied in the newly 
completed emergency change in step 520 and then closes the emergency change request in step 
530. 

EXAMPLE 3: COMPUTER IMPLEMENTATION 
[0042] Sample screens from a version of the Change Management Procedure implemented on 
a computer system are shown in Figures 3, 4, 5, 6, 7, 8, 9, and 10. Figure 3 is an example of a web 
page users can use to log in to the computerized version of the Change Management Procedure. 
The user's name and password are entered in fields 610 and 620, respectively. Registered users 
use button 630 to log in to the change management system. New users who wish to register 
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themselves into the system can use button 640. Button 650 provides help to users who cannot 
remember their passwords. 

[0043] Figure 4 is an example of a web page that displays active change requests. Column 710 
allows a user to select whether a change request is to be viewed or edited and also allows a search 
to be performed. Column 720 lists the identification numbers of the change requests. Column 730 
displays the titles of the change requests. Column 740 displays the customers requesting changes. 
Column 750 shows the status of the change requests. Column 760 displays the group to which the 
change requests have been assigned. Column 770 displays the individuals who submitted the 
change requests. Column 780 lists the dates the changes requests were submitted. 
[0044] Figure 5 is an example of a menu listing the options available to a user who has a 
security level of 3. Field 810 allows the user to log out. Field 820 allows a user to edit user 
information. Field 830 allows a user to display the change request list. Field 840 allows a user to 
enter a new change request. 

[0045] Figure 6 is an example of a menu listing the options available to a user who has a 
security level of 4. Field 910 allows the user to log out. Field 920 allows a user to edit user 
information. Field 930 allows a user to display the change request list. Field 940 allows a user to 
enter a new change request. Field 950 gives a user access to the user management screen. Field 
960 gives a user access to the email group management screen. 

[0046] Figure 7 is an example of a web page users can complete to register themselves into the 
computerized version of the Change Management Procedure or to edit previously entered 
registration information. The user's first name and last name are entered in fields 1010 and 1020, 
respectively. The user's email address is entered in field 1030. The user's business phone number, 
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mobile phone number, pager number, and pager PIN are entered in fields 1040, 1050, 1060, and 
1070, respectively. The user's password is entered in field 1080 and is confirmed in field 1090. 
Button 1095 is used to submit a completed registration form. An email notification is sent to the 
change manager when the user submits the registration information for authentification. Another 
email is sent to the user when the change manager authenticates the user and assigns the 
permission level of the user. 

[0047] Figure 8 is an example of a section of a web-based change request document. A short 
description of the proposed change is entered in field 1 102. This becomes the title of the change. 
The change request type is entered in field 1104, the customer category is entered in field 1106, 
and the group initiating the change request is entered in field 1 108. The latter three fields are drop- 
down boxes allowing the user to choose from a predefined list of valid entries. Fields 1 1 10, 1 1 12, 
1114, 1116, and 1118 allow the user to specify the trouble ticketing system associated with the 
proposed change. The location of the organization requesting the change is entered in field 1 120. 
The name and phone number of the change requester are entered in fields 1122 and 1124, 
respectively. If a person in the requesting organization other than the change requester oversees 
the change request process, that person's name and phone number are entered in fields 1 126 and 
1 128, respectively. The names and phone numbers of the change implementer or implementers are 
entered in fields 1 130, 1 132, 1 134, 1 136, 1 138, 1 140, 1 142, and 1 144. Field 1 146 is a scroll box in 
which one or more types of devices or systems to which the proposed change applies are chosen. 
Field 1 148 is a scroll box in which organizations potentially impacted by the proposed change are 
chosen. Button 1150 allows a user to save a partially completed change request form without 
submitting the form. Button 1152 allows a user to submit a completed form to the change 
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manager. Additional sections of the web-based change request document, not shown, may include, 
but are not limited to ? a detailed description of the change, details of the device, software, or 
facility affected, database or application outages due to the change, the test plan and test results, 
and the backout plan. 

[0048] Examples of email distribution lists are shown in Figure 9. Radio buttons 1210, 1220, 
and 1230 allow a user to select the distribution list to which an email should be sent. Button 1240 
takes the user to a screen that allows new email distribution groups to be created. 
[0049] The screen used to edit the email distribution lists is shown in Figure 10. Email 
distribution lists allow the ability to tailor the broadcast notifications and review team notifications 
to specific team members based on the status of the change request, who initiated the change, the 
content of change, or any combination of the three. The group name of the distribution list is 
entered in field 1310. The change request status that causes an email to be sent to the specified 
group is selected in field 1320. The organization to which the specified group belongs is selected 
in field 1330. The department within the organization is selected in field 1340. A description of 
the group can be entered in field 1350. The individuals within the group are listed in field 1360. 
Button 1370 is used to submit updated information after changes have been made to the other 
fields on the screen. Button 1380 is used to delete a group and button 1390 is used to cancel any 
changes and return the group's information to its previous state. 
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